测试右移之日志收集与监控
读完需要
14分钟速读仅需 5 分钟
我在敏捷测试系列直播课程里讲到了《测试右移》，也就是收集生产环境的数据信息，分析和利用这些信息优化软件开发和测试环节，以进一步提高质量。生产环境的数据信息中最为重要的就是日志信息，因此，收集日志信息并利用日志信息进行监控也是测试右移最重要的内容。
本文将从日志收集的必要性、日志收集方案、日志监控机制和高效日志管理实践几个方面跟大家一起探讨测试右移之日志收集与监控。
👀
日志收集的必要性
随着科技的发展，业务形态、业务类型、业务复杂度都发生了很大的变化，相应地，业务数据量和复杂度也增加了不少。为了支撑复杂的业务和大的数据量，技术架构和基础设施也在演进变化。所有这些因素，导致软件系统生态变得日益复杂和不确定。而在处于不确定状态的软件系统，传统的软件测试方法显然行不通，于是利用生产环境信息，尤其是其中的日志信息，成为了新时代软件质量保障的必要条件。
那么，日志信息这么重要，它的价值到底体现在哪里呢？我认为至少有以下四个方面的价值：
1. 定位功能问题
当我们的软件系统出现 bug 的时候，最常用的诊断方式就是尝试重现并且查看日志记录。因此，日志信息帮助诊断和定位功能问题应该是人人皆知的一种诊断方法，无需赘述。
2. 展示性能趋势
日志信息可以记录到请求的响应状态、时间等，利用这些信息可以分析得出系统的性能状态。如果对一段时间内的性能状态进行持续的分析监控，就可以展示性能趋势变化。
3. 暴露安全隐患
日志信息可以记录数据被访问的情况，对于较为严重的业务安全问题，比如数据被越权访问的情况，可以很好的利用日志信息来暴露。
4. 优化业务价值
利用日志信息，可以分析出哪些业务模块或业务流程被访问较多或较少、用户行为习惯是什么样的等，而这些是可以进一步分析来优化企业业务价值的。
👀
日志收集方案
日志信息的价值这么大，那就赶紧利用起来吧。
日志收集痛点
不过，也不是那么简单的事情，因为日志信息的收集还是有不少痛点的：
生产环境访问受限，通常日志信息源文件不会像测试环境那样可以被团队任何人被访问；
就算有权限访问，生产环境较为复杂，一般都为多服务器环境，加上微服务架构，日志文件也是分散在不同的服务器上的多个不同服务下面，不便查询；
详细的日志信息数据量会非常大，日志里边还会有类似的或者重复的信息，更增加了查询复杂度
针对这种日志信息复杂的情况，我们需要一个集中管理日志的方案。
集中日志管理
集中的日志管理方案需要满足以下条件：
统一收集：将分散在不同地方的日志信息用相同的方式统一收集起来进行管理；
统一存储：统一收集的日志信息存储在同一个独立的地方（库），在不影响日志源文件的情况下，可以对收集到的统一存储的日志进行查询和分析；
筛选和解析：有过滤和聚合的功能，可以通过指定条件对日志进行筛选和解析；
方便检索：统一存储的日志需要有统一的索引，能够方便用户进行检索。
利用上述方案集中管理的日志，就可以快速对日志进行查询，可以通过图表的方式展示系统应用运行情况，并且根据日志数据设置规则对异常情况进行自动报警。
集中日志管理工具
既然有这个需求，自然也是有很多工具支持的。目前，集中日志管理工具最常见的有两个：Splunk 和 ELK。下面简单介绍，更多详细内容请自行网上搜索。
Splunk
Splunk 是一款功能强大的商业日志管理系统，称为“Data-to-Everything”平台，功能齐全，搜索方便，当然价格也不菲。
ELK 框架
ELK 分别是 Elasticsearch、Logstash、Kibana 三个工具首字母，而这三个工具分别为日志收集提供不同的功能：
Elasticsearch 是一款搜索框架，提供方便的接口，可以做全文检索，可以用来对日志进行检索。
Logstash 是数据收集工具，用来收集日志数据。
Kibana 是可以和 Elasticsearch 交互的界面，通过 Kibana 可检索 Elasticsearch 内的所有数据，并用图形化方式展示数据结果。
图片来自:https://user-images.githubusercontent.com/30971809/54028642-fb1e7f80-41a5-11e9-9873-1e2b6c316615.png
日志存在的问题以及优化方案
日志集中管理方案和工具都介绍了，在日志集中收集的过程中还可能遇到哪些问题呢？根据我的经验，日志本身可能存在下列问题：
1. 级别定义不清晰
通常定义的打印日志级别从高到低有：
FATAL | 致命：指明非常严重的可能会导致应用终止执行错误事件。
ERROR | 错误：指明错误事件，但应用可能还能继续运行。
WARN | 警告：指明可能潜在的危险状况。
INFO | 信息：指明描述信息，从粗粒度上描述了应用运行过程。
DEBUG | 调试：指明细致的事件信息，对调试应用最有用。
TRACE | 跟踪：指明程序运行轨迹，比 DEBUG 级别的粒度更细。
除了上面几类级别，也可以根据自己团队的情况自定义日志级别，比如可以根据响应级别（响应的方式、需要参与的人员等）来定义日志级别。
如果这些日志级别定义不清晰导致日志级别乱用，就会带来浪费或者错过重要的日志信息。比如：之前项目经历过大量的“警告”级别日志被误记为“错误”，团队花费大量的时间处理本不需要处理的日志信息。
因此，对日志级别的规范定义非常重要。不管采用什么级别定义，务必要让团队都能清晰的知道，并且严格按照所定义级别来添加日志信息。
2. 存储路径不一致
多个微服务由不同团队开发的情况可能导致不同服务的日志存储路径不一致，这样用工具来集中收集的话可能遗漏某些日志信息。我们团队在初期使用 Splunk 收集日志的时候就发生了这种情况。
因此，需要在团队内部统一日志存储路径，并且在使用工具集中收集的时候要确保所有服务的日志信息都能正常导入。
3. 日志信息不够用
日志记录是为了帮助诊断定位问题，如果日志信息不全，就不仅不能帮助诊断定位问题，还增加了很多额外的开销，是毫无价值的。
比如，有些日志只是记录了错误代码，具体进行什么操作、哪个请求出错等有用的信息都缺失，这样的日志是完全没有用的。
除了不够用，可能还有一种情况是日志信息记录过剩，导致没有必要记录的、或者一些个人隐私信息等都记录在日志里，这也是不行的，这个问题可能更严重，也就是可能存在安全隐患。
因此，团队对日志需要记录的信息达成共识，确保记录足够有用，且没有安全隐患。
4. 记录格式不一致
日志记录的格式也是有要求的，需要统一格式，这个主要是方便日志收集工具进行过滤和聚合。如果不同的服务或者不同的功能模块记录的日志格式不一致，就很难通过工具聚合的方式处理同一类型的日志，给日志出来带来很大的不便。
这种情况推荐使用“结构化日志”技术，将日志格式统一、规范的记录清楚。
结构化日志（Structured Logging），也叫语义化日志，主要是为了增加日志的可读性，比如在日志中增加相关特性代号、请求的顺序等信息，帮助运维人员理解优先级，快速定位问题，沟通更加顺畅。
PS: 结构化日志请参考: https://www.thoughtworks.com/radar/techniques/structured-logging
👀
日志监控机制
日志集中收集管理以后，下一步就是将收集到的日志数据进行分析并可视化，然后利用这些分析结果，通过一定的规则设置，对异常情况进行监控预警。
监控的难点
日志监控预警有几个难点，那就是日志监控的内容、形式和响应机制，这几点要处理好才能做好日志监控预警。
1. 监控预警的内容
进行监控之前务必搞清楚需要监控什么内容，哪些服务需要重点监控？有哪些异常场景需要发出预警警报？为什么？
可以从以下三个方面去考虑：业务功能、性能指标、安全漏洞。
业务功能：确保业务功能的正常运转，可能对于关键业务需要进行监控，一旦有异常的业务场景出现根据严重程度需要发出警报。因此，需要确认哪些是关键业务。
性能指标：对于有明确性能指标要求的服务/页面、技术角度有性能担忧的 API，要进行重点监控。
安全漏洞：对于权限控制比较严格的模块，需要监控是否有信息越权访问等漏洞，这块还需要结合具体业务考虑有哪些需要监控的内容。
2. 监控预警的形式
确定了监控的内容，下一步就是要确定监控结果如何展示、预警警报该以什么方式发出。通常有以下三种方式：图表展示、邮件通知、即时消息或电话报警。
图表方式展示的信息较全面，方便分析，适合优先级较低的信息，需要人为主动去查看。
邮件通知应以异常触发，不宜定时、过多的发送，适合优先级较高的异常场景。之前就有团队经历过定时通过邮件发送警报的情况，结果由于其中有些优先级并不是很高，导致到后来没人看警报邮件，真正有高优先级的情况也不能被及时发现。
即时消息和电话警报适合特别紧急的故障，需要及时处理，优先级最高。
3. 监控预警的响应机制
监控的内容和形式确定了，监控预警可以搞起来了。不过，一旦异常发生，团队该如何响应呢？这时响应机制就特别重要了。响应机制需要从以下三个方面去做工作：响应级别、职责到位、反馈回顾。
清楚定义不同的响应级别、以及对应级别的行动很重要，确保对待不同优先级的故障有不同的响应速度和响应方式。
响应职责分配到人或者角色，确保负责人都清晰了解响应级别的含义，知道具体要采取行动，一但发生故障能够有及时的处理。
定期收集团队对于监控预警的反馈，并总结回顾，以持续地改进优化监控预警机制。
日志可视化与监控工具
日志信息的可视化对监控至关重要，可视化后可以直观、清晰的看到数据走势，方便和历史数据进行对比，提高分析效率；可视化除了可以针对一段时间的趋势性数据，还可以是针对实时搜索结果，也可以是根据条件设置的实时监控数据。
前面介绍的工具 Splunk 和 ELK 的 Kibana 都具备很好的日志数据可视化功能。
Splunk
Splunk 提供列表、线状图、饼状图和柱状图等的可视化方式清晰展示统计分析结果。下图是来自 Splunk 官方提供的可视化文档：
同时，Splunk 还提供报警功能，可以在 Splunk 里根据不同规则设置各种不同的自动警报。
Kibana
ELK 里的 Kibana 是专门针对 Elasticsearch 的图形化操作工具，能够对 Elasticsearch 的数据进行检索，也可以将结果图示化展现。如下图示：
ELK 本身只提供基础的日志管理框架，自动报警功能需要安装插件来实现。
有效的监控机制
工具可以帮助我们更好的做好日志收集和监控，但是更重要的是需要一套完善的机制来保障。要做到有效的监控，务必做到以下几点：
收集足够的日志信息，做好日志数据的可视化；
明确要监控的内容、形式和响应机制，制定监控策略；
确保相关负责人职责清晰，对响应的行动要求达成共识；
需要有相应的跟踪、分析策略，定期收集反馈，总结、回顾并与团队充分沟通。
👀
高效日志管理实践
前面介绍了日志管理的相关技术和实现方案，任何实践对应的技术都不是最麻烦的，往往实践过程中遇到的与人相关的问题才最为关键。对于测试右移之日志管理实践，跟大家理解的仅仅采用相关技术实现的日志管理有何不同？又如何才能做的高效呢？
项目日志管理案例
本案例是一个开发多年的由单体架构演进为微服务的 web 项目，随着微服务的规模化，大量错误日志出现，引起了团队对日志管理的重视，从最初的运维人员单独管理日志，到后来的测试人员与运维人员通力合作，日志管理实践发生了好几次的演进变化，主要经历了如下阶段：
初期被动分析：只是 Ops 人员参与日志分析，利用 Splunk 工具每天处理 top 10 的日志。
主动出击内建日志：QA 与 Ops 合作，从流程上规范化日志收集与监控，把日志内建到所开发的软件系统里，成为软件系统代码的一部分。
QA 主导进一步优化：QA 在此期间承担协调者和分析者的角色，主导团队的日志收集与监控工作，跟 Ops 进行跟深层次的合作，充分发挥各自所长。
关于这三个阶段的更多细节，请参考文章《QA 与 Ops 通力合作打造反脆弱的软件系统》。
高效日志管理方案
通过前面对日志收集与监控的技术和实践介绍，结合项目日志管理案例，总结出日志管理的高效方案包括以下几点：
制定一个日志管理的策略：作为指导方针的策略永远都是重要的，只有方向对了，才有可能把事情做好。
结构化日志数据：利用结构化日志技术来记录日志，可以使得日志收集与监控容易很多，不过日志结构里都包含什么内容，也是需要好好设计的；日志记录的信息要尽量做到刚刚好，少了会不利于问题诊断，多了是浪费，而且有可能带来安全风险，要特别注意隐私信息不能记录到日志里。
使用唯一标识符：不同系统、服务记录日志都采用唯一标识符，将有利于日志信息的集中统一管理。
集中日志管理：这是日志管理的根本，只有集中管理所有日志，才能充分利用日志信息。
可视化日志数据，设置实时监控：日志数据可视化能够更好的展示分析结果，设置实时监控在用户报出问题之前发出警报，能够加快问题修复和降低损失。
利用日志信息分析趋势：利用日志信息分析性能趋势、功能特性使用趋势，可以更进一步指导分析业务发展情况。
团队参与日志内建和管理：团队不同角色的共同参与能够让日志管理更有效、价值更大化。